During ordinary operation of computer networks it is usual for a client to access a server and to request access to a resource provided by that server. A client may be thought of as a program running on a work station, desktop type computer, personal digital assistant (PDA) or even an embedded device, and a server may be thought of as a program performing a service for a plurality of clients. The client may also be thought of as the computer running the client software, and the server may also be thought of as the computer running the server software. For some purposes, the client may be thought of as a user on whose behalf a request is being made. In some cases, the same computer may run both the client software and the server software. The service is ordinarily provided by the execution of a server program at the request of the client. Specifically, the service provides a resource to the client. The resource may be any operation that is executed, affected or controlled by a computer, such as a word processing or spread-sheet program, the transfer of files, or some other data processing function. The resource access may also include the ability to read or to modify entries in a data base, execute or modify a program maintained by the server, or even modify data maintained by another computer in the system.
In deciding whether or not to grant access to a resource, a resource server must answer two questions:                A. “Is the client correctly identifying himself?” and        B. “Is the identified client authorized to access the requested resource?”The first question involves a process called “client authentication.” The second involves reference to an authorization decision mechanism, such as an Access Control List (ACL) maintained by the server and containing a list of individual clients and/or client groups who are permitted access to the resource. The present invention relates to the determination of group membership or group non-membership of resource-requesting clients.        
Client authentication can be accomplished using public key cryptographic methods, as described in Network Security, Private Communication in a Public World, Charlie Kaufman, Radia J. Perlman, and Mike Speciner, PTR Prentice Hall, Englewood Cliffs, N.J., 1995, (Kaufman et al.) at chapters 5, and 7 and 8, pages 129-161 and 177-222. Specifically, client Alice can authenticate herself to resource server Bob if she knows her private key and Bob knows Alice's public key. Bob has obtained Alice's public key in an identity certificate from a trusted certification authority or from a certification authority in a chain extending from a trusted authority. Other methods of authentication may be used and the present invention does not depend on which method is used.
An identity certificate may be revoked. One common method of dealing with revocation involves the use of Certificate Revocation Lists (CRLs) which are analogous to the books of revoked credit card numbers that were at one time published and distributed periodically to merchants. Like these books, CRLs suffer from being expensive to distribute and are therefore infrequently distributed. There may also be a significant period of time between certificate revocation and CRL distribution during which the resource server is unaware of the revocation.
For maximum security, the certificate authority may be off-line and therefore inaccessible on a transaction-by-transaction basis. Moreover, issuance of an identity certificate may be a relatively lengthy process so that, even if the certificate authority is on-line, it is impractical to issue an up-to-date certificate for each transaction. An alternative approach to certificate revocation involves the use of on-line revocation servers which maintain lists of revoked identity certificates. With on-line revocation servers, up-to-date revocation status can be determined.
At the same time, if a revocation server's private key has been compromised, the damage will be more limited than if an on-line certification authority's private key were compromised. Specifically, if the certification authority's private key were compromised, the authority might issue new certificates to unauthorized clients. On the other hand, a compromised revocation server would result only in continued access by a client with revoked authorization. A compromised revocation server can never grant unauthorized access to a client who has never had authorized access. Although a compromised revocation server may wrongly revoke an authorized client, the revocation would only be a denial-of-service attack.
The use of on-line revocation servers, which is analogous to the method employed today for the authorization of credit card purchases, is also expensive because the resource server usually contacts an on-line revocation server at each transaction to determine whether the certificate has been revoked. The OCSP (On-line Certificate Status Protocol) Internet draft of the PKIX working group, draft-ietf-pkix-ocsp-07.txt (posted September, 1998, at <http://www.normos.org/ietf/draft/draft-ietf-pkix-ocsp07.txt>), specifies that the revocation status for each certificate can be retrieved from the revocation server and cached by the resource server verifying that certificate. Although caching improves resource server efficiency, it still places a burden on the resource server which may already be burdened with the processing of resource access requests.
An authentication and authorization arrangement introduced by the Open Software Foundation (OSF) and known as the Distributed Computing Environment (DCE) model has a central database on a machine known as a “privilege server” or “central trusted authority.” When a client logs on to the system the privilege server issues a secret, or symmetric, key certificate (as opposed to a public, or asymmetric, key certificate) identifying all the groups of which the client is a member. The client presents this certificate to any server on which the client wishes to access a resource. The resource server has an ACL for the resource, and the ACL includes both authorized clients and client groups. If neither the client nor any one of the groups of which the client is a member is listed in the ACL, client access is denied. This approach saves some work for the server, but requires that a central trusted authority know all the groups of which the client is a member and also that the client's group list is small enough so that presentation of the entire collection is not unwieldy. The DCE model is described in Kaufman et al. at Section 17.7, pages 455-459.
Another approach to authentication and authorization is provided by the Windows NT operating system, a product of the Microsoft Corporation of Redmond, Washington. NT has the concept of “domains” where a local group is known only within that domain, although clients from other domains can be members of a local group. NT also has “global” groups whose members must be individuals (not groups) from one domain. A global group of one domain can be listed as a member of a local group in any other domain having a trust relationship to the first domain. Much like DCE, this approach also uses a central trusted authority.
The existing network approaches are inflexible in that they use a central trusted authority and/or provide for the issuance of group certificates only on certain occasions, such as when a client joins a group or logs onto the system. Furthermore, a group server will not issue a group certificate for a particular client unless that client is explicitly listed on its group membership list. These limitations hamper the implementation of a “nested” group, wherein a group has other groups, i.e., subgroups, as members and client membership in the nested group may be indirectly proven through client membership in a sub-group. Nested groups are difficult to implement on existing systems because, among other things, the membership lists of each of these groups may be stored on different machines on the network. Therefore, what is needed is a more flexible approach to the issuance of group certificates.